home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1992 June: ROMin Holiday / ADC Developer CD (1992-06) (''ROMin Holiday'')_iso / Developer Connection - 06-1992.iso / Development Platforms / Apple II / Essentials / Technical.Notes / IIGS / TN.IIGS.002 < prev    next >
Encoding:
Text File  |  1988-12-16  |  6.8 KB  |  134 lines  |  [TEXT/pdos]
  1. Apple II
  2. Technical Notes
  3. _____________________________________________________________________________
  4.                                                   Developer Technical Support
  5.  
  6.  
  7. Apple IIGS
  8. #2:    Transforming I/O Subroutines for Use in "Native" Mode
  9.  
  10. Revised by:    Pete McDonald                                    November 1988
  11. Written by:    Pete McDonald                                     October 1986
  12.  
  13. This Technical Note outlines a number of techniques useful when transforming 
  14. Apple II I/O subroutines for use in the "native" Apple IIGS environment.
  15. _____________________________________________________________________________
  16.  
  17. The Apple IIGS execution environment represents quite a departure from the 
  18. environment to which the average Apple II developer is accustomed.  This fact 
  19. results in a number of unique problems when one attempts to convert existing 
  20. Apple II applications for use in the "native" Apple IIGS  environment.  (Note:  
  21. If you intend to let your application remain an eight-bit "classic" Apple II 
  22. application, then you can ignore the information this Technical Note 
  23. presents.)
  24.  
  25. I/O subroutines which depend upon critically timed code present some of the 
  26. biggest conversion problems due to two major issues.  In the native IIgs 
  27. environment, you cannot guarantee that there will be memory available in a 
  28. given bank, and I/O locations are not available in every bank.
  29.  
  30. There are a number of possible solutions to this problem.  Which ones you 
  31. should use depend upon what the program in question is doing.  This Note 
  32. attempts to describe some of the problem situations and possible solutions.
  33.  
  34. Examine the 6502 code segment below.  It serves no useful purpose, other than 
  35. to illustrate a simple manifestation of the problem.  Assume IoLoc is a 
  36. location in the $C000 - $CFFF range of memory.
  37.  
  38.     Loop    LDA    IoLoc
  39.             DEY
  40.             BPL    Loop
  41.  
  42. Because the $C000 - $CFFF range of memory in bank 2 or higher contains RAM 
  43. instead of I/O circuitry unless hardware shadowing is enabled, if you place 
  44. the fragment above in one of these banks, it will have no effect on the I/O 
  45. device you intend it to control.
  46.  
  47. There are two possible solutions in this case.  Either change the instruction 
  48. LDA IoLoc so it uses long addressing, thereby forcing the CPU to reference the 
  49. the proper bank.  (Note:  The problem with this is the long version of LDA 
  50. requires an extra CPU cycle to execute.  If the code segment is timing 
  51. critical, then this method is likely to be unacceptable.)  Alternately, in the 
  52. timing-critical case, we could set the data bank register before entering the 
  53. loop which would mean the LDA IoLoc would take the same number of cycles as it 
  54. did previously, thus leaving the timing loop unchanged.
  55.  
  56. These solutions seem pretty easy; therefore, you know there is a catch.  The 
  57. catch, unfortunately, is that most code is not isolated as in the example.  
  58. Specifically, code commonly tries to load from or store to some location in 
  59. memory other than the I/O location at the same time it is trying to access the 
  60. I/O location.
  61.  
  62. Take, for example, the following fragment:
  63.  
  64.     Loop    LDA    Data,y
  65.             STA    IoLoc
  66.             DEY
  67.             BPL    Loop
  68.  
  69. In this example, we assume that the label Data refers to some kind of table 
  70. which normally resides in the same bank as the program.  Now if you set the 
  71. data bank register to access I/O locations, then the reference to Data will 
  72. also reference the same bank as the I/O; this solution is likely not 
  73. acceptable.  One thing you can do is move the data table to the direct page 
  74. (zero page for 6502 programmers), but now the LDA Data,y instruction will take 
  75. one less cycle to execute.  There is a solution, although it is a little 
  76. complicated.  If we set the direct page register to a non page-aligned 
  77. location, then we effectively apply a one-cycle penalty to all direct page 
  78. references and solve our problem.
  79.  
  80. Of course, nothing is ever as simple as it seems.  What happens to references 
  81. to other direct page locations that expect to operate without the one-cycle 
  82. penalty?  To properly address this question, I would need much more space than 
  83. I have here, so in lieu of further examples, I offer some general information.  
  84. (As an aside, I used these techniques to transform the old "Apple II Disk II 
  85. formatter module" for use in any bank of memory in the native IIGS 
  86. environment.  I accomplished this using, almost exclusively, editor find and 
  87. replace commands, and I finished in hours instead of the days which would have 
  88. been required to completely rewrite the program.)
  89.  
  90. In addition to the techniques already covered, there are a few other things 
  91. which may be necessary to complete a transformation (they were necessary in 
  92. the case of the formatter module).
  93.  
  94. As I already mentioned, one problem is what to do in the case where a program 
  95. references I/O, local program-bank data, and the zero-page.  In this case, 
  96. significant rewrites could be required, but not necessarily.
  97.  
  98. In the case of the disk formatter, it turned out that some modules used both 
  99. normal zero-page addressing and normal 16-bit absolute indexed addressing.  
  100. Since the transformation process dictates that we change 16-bit absolute 
  101. addressing to direct-page addressing with a non page-aligned direct page, 
  102. there could have been a problem had both uses of the direct page been timing 
  103. critical.  Fortunately, by treating each module of the program separately, 
  104. when I needed both types of addressing, only one was critical.  The solution 
  105. was to set the direct page to a non page-aligned value in some modules and to 
  106. a page-aligned value in others.  There are some minor logistical issues when a 
  107. direct page's base address can be at either $xxx0 or $xxx1, the biggest of 
  108. which is keeping track of which is in effect at a given point and knowing to 
  109. reference the label as label, label+1, or label-1, depending upon the 
  110. particular case.
  111.  
  112. With the formatter transformation, there was one other major issue:  there are 
  113. not direct-page versions of all the 16-bit absolute addressing modes (i.e., 
  114. one cannot convert 16bitaddress,x to 8bitaddress,x).  In the case of the 
  115. formatter, I was able to solve this by reversing all the register use (i.e., 
  116. all LDY instructions became LDX instructions, all STY instructions became STX 
  117. instructions, etc.).
  118.  
  119. There are still a number of other ways in which one can approach these issues; 
  120. one that comes to mind would be using some form of the new stack-relative 
  121. addressing modes to yield yet another range of semi-independently accessible 
  122. addresses.
  123.  
  124. The real point of this Technical Note is that with a little thought and 
  125. effort, one can successfully convert a large subset of likely configurations 
  126. for use in the native IIGS environment without major rewrites.  The bottom 
  127. line is to be creative!
  128.  
  129.  
  130. Further Reference
  131. o    Programming the 65816 Including the 6502, 65C02, and 65802 (Eyes/Lichty)
  132. o    Apple IIGS Firmware Reference
  133.  
  134.